The present invention relates to a parts management. FIG. 6 shows a conventional parts management information system. Managing terminals 133-1, 133-2, and 133-3, and storage means (databases) 132-1, 132-2, 132-3, and 132-4 are connected to a central processing unit (CPU) 131.
The databases of parts used are hierarchically managed in units of managed items: for example, the parts master 132-1, inventory master 132-2, unit-price master 132-3, and schedule master 132-4.
The terminals 133-1, 133-2, and 133-3 are used to refer to or update data on the databases 132-1, 132-2, 132-3, and 132-4. For example, when parts in stock are referred to, the operator refers to the inventory master 132-2 from one of the terminals 133-1, 133-2, and 133-3. As the number of parts to be dealt with becomes larger, the number of orders on the database increases cumulatively.
FIG. 7 shows a display example of the spreadsheet format. The operator searches the displayed contents for a part used, and compares the dates of “final delivery date” and “date of completion (acceptance)” to check if there is any delay. If the date of completion is blank, this means that the part is not yet complete, and the operator determines that the part is still in a shop in an intermediate process.
Since the display in the spreadsheet format is a set of data based on given key information, the operator often cannot directly and quickly confirm the status, such as expected orders in his or her shop (the number of expected orders), delay (the number of parts that have not yet been accepted), order determination (the number of jobs which are in progress after their specifications have been determined), acceptance (the number of accepted orders), and the like.
More specifically, in order to obtain conclusions (the number of complete parts, delivery on the delivery date or not, and so forth) required for shop management, data must be interpreted manually. In the above example, the operator or shop manager must compare the “final delivery date” and “date of completion”.
The aforementioned conventional parts management information system suffers the following problems.
1. It is hard to inform the operator or shop manager of an abnormal condition such as a delay in scheduling, in real time.
2. In order to selectively search for required information while classifying parts used in the primary shop and those used in other shops, the operator must find out required data from a list.
3. Orders received by the primary shop and those placed with other shops are not easy to manage and confirm from the data in the spreadsheet format.
4. Parts management that displays data in table format displays data based on key information, and limits versatile analysis that requires order placement/receipt processing status of shops in units of days and comparison of a plurality of data. In order to compensate for such limitations, the operator must perform manual analyzes based on the data displayed.
However, in such analysis, as the shop becomes larger, the number of orders to be processed becomes huge, and it is hard to inform the operator or shop manager of abnormal conditions such as a delay in scheduling and the like at desired times. Hence, in practice, such display is not effective for operation of shops.
5. A conventional parts management information system provides a uniform data display based on a specific condition, and must use a plurality of applications to confirm the total status and detailed status by search in order to perform receipt/placement processing of shops. In such a case, a search must be made while confirming integrity of data, and the works required for parts management become troublesome. As the shop becomes larger and the number of orders to be processed become huge, it is difficult to relate the overall processing status in detailed information by a conventional uniform display.